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Abstract — We are interested in unicast traffic over wireless 
networks that employ constructive inter-session network coding, 
including single-hop and multi-hop schemes. In this setting, 
TCP flows do not fully exploit the network coding opportunities 
due to their bursty behavior and due to the fact that TCP is 
agnostic to the underlying network coding. In order to improve 
the performance of TCP flows over coded wireless networks, 
we take the following steps. First, we formulate the problem 
as network utility maximization and we present a distributed 
solution. Second, mimicking the structure of the optimal solution, 
we propose a network-coding aware queue management scheme 
(NCAQM) at intermediate nodes; we make no changes to TCP or 
to the MAC protocol (802.11). We demonstrate, via simulation, 
that NCAQM significantly improves TCP performance compared 
to TCP over baseline schemes. 

Index Terms — Network coding, wireless networks, congestion 
control, transport protocol design, queue management. 

I. Introduction 

Wireless environments naturally lend themselves to network 
coding, thanks to the inherent broadcast and overhearing 
capabilities of the wireless medium. We are particularly in- 
terested in wireless mesh networks that employ constructive 
network coding schemes (such as COPE HI and BFLY J6)), to 
mention some concrete examples). We consider unicast flows 
(particularly TCP, which is the dominant traffic type today) 
transmitted over such coded wireless networks. 

In this setting, it has been demonstrated that network coding 
can significantly increase throughput |fl~), 13- However, it 
has also been observed |T| that TCP does not exploit the 
full potential of the underlying network coding, mainly due 
to its bursty behavior. Rate mismatch between flows can 
significantly reduce the coding opportunities, as there may not 
be enough packets from different flows at intermediate nodes 
to code together. One possible solution is to artificially delay 
packets at intermediate nodes [3 j, until more packets arrive and 
can be coded together. However, the throughput increases with 
small delay (due to more coding opportunities), but decreases 
with large delay (which reduces the TCP rate); the optimal 
delay depends on the network topology and the background 
traffic and also may change over time. Thus, in many practical 
networking scenarios, introducing delay at intermediate nodes 
is not practical. 

We consider the same problem but we propose a different 
approach. Our main observation is that the mismatch between 
flow rates is due to the dynamic/bursty nature of TCP. There- 
fore, the problem can be eliminated by making modifications 
to congestion control mechanisms (at the end-points) and/or to 



queue management schemes (at intermediate nodes) to make 
them network coding-aware (in the sense that they can match 
the rates of flows coded together). Based on this observation, 
we take the following steps. 

First, we formulate congestion control for unicast flows over 
wireless networks with inter-session network coding within the 
network utility maximization (NUM) framework (4), J5J. We 
assume that a known constructive network coding scheme is 
deployed in a wireless mesh network; examples include COPE 
HI for one-hop network coding and BFLY J6) for two-hop 
network coding. The optimal solution of the NUM problem 
decomposes into several parts, each of which has an intuitive 
interpretation, such as rate control, queue management, and 
scheduling. 

Second, motivated by the analysis, we propose modifica- 
tions to congestion control mechanisms, so as to mimic the op- 
timal solution of the NUM problem and to fully exploit the po- 
tential of network coding. It turns out that the optimal solution 
dictates minimal and intuitive implementation changes. We 
propose a network coding-aware queue management scheme 
at intermediate nodes (NCAQM), which stores coded packets 
and drops packets based on both congestion state and network 
coding. We note that the queues at intermediate nodes, which 
are already used for network coding, are a natural place to 
implement such changes with minimal implementation cost. 
In contrast, we do not propose any practical modifications to 
TCP or MAC (802. 1 1) protocols, which significantly simplifies 
practical deployment of our proposal. Finally, we evaluate 
our proposal via simulation in GloMoSim l23l and we show 
that TCP over NCAQM significantly outperforms TCP over 
baseline schemes (e.g., doubles the throughput improvement 
in some scenarios), and achieves near-optimal performance. 

The rest of the paper is organized as follows. Section [TT] 
discusses related work. Sections [TTlti VII focus on wireless 
networks with one-hop network coding: Section [Til] presents 
the system model; Section HVl presents the optimization prob- 
lem and solution; Section [V] presents the design of our 
network coding-aware queue management scheme (NCAQM); 
Section [VI] presents simulation results. Section IVIII extends 
our framework to multi-hop network coding. Section IVIIII 
concludes the paper. Appendix A presents numerical results 
for the convergence of the solution. 

II. Related Work 
This paper builds on top of constructive network coding 
schemes in wireless mesh networks. We rely on such a given 
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scheme to provide the available coded and uncoded flows to 
higher layers. We then seek to optimize the treatment of these 
flows at the end-points and/or at intermediate nodes so as to 
maximize network coding opportunities. 

COPE and follow-up work. COPE JT| is a constructive 
network coding scheme for one-hop network coding across 
unicast sessions. Our framework can also consider any other 
constructive scheme for inter-session NC, such as BFLY |6| 
or tiling approaches [7 |. COPE has generated a lot of interest 
in the research community. Some researchers tried to model 
and analyze COPE 03) . fl5) . ifTTl . Some others proposed 
new coded wireless systems, based on the idea of COPE II 1 611 . 
J6). Zhao and Medard tried to explain and improve COPE's 
performance by looking at its interaction with MAC fairness 
03). We note that the authors of COPE had noticed the 
problem with TCP performance over COPE. As discussed in 
the introduction, [3) addressed the problem of rate mismatch 
between flows that are coded together, by delaying packets. 
Here, we take a different approach and we create coding 
opportunities via queue management and congestion control. 
More specifically, we aim at improving TCP performance 
over COPE by complementing it with a network coding-aware 
queue management scheme (NCAQM). 

NUM in coded systems. Our analysis falls within the classic 
framework of network utility maximization (NUM) J5). A 
significant body of work has looked at the joint optimization 
of intra- or inter-session NC of unicast flows. For example, 
in (8), minimum cost multicast over network coded wireline 
and wireless networks was studied. This work was extended 
for rate control in J9) for wireline networks. The rate region 
of multicast flows when network coding is used is studied 
in iflOl . ifTTTl . The most closely related to this paper are re- 
source allocation problems for unicast flows. For example, rate 
control, routing, and scheduling for generation-based intra- 
session network coding over wireless networks is considered 
in 021 ■ Optimal scheduling and optimal routing for COPE 
are considered in lfl3l and IfTTl . respectively. Network utility 
maximization is used in lfl8l for end-to-end pairwise inter- 
session network coding. Energy efficient opportunistic inter- 
session network coding over wireless are proposed in lfl9) . 
following a node-based NUM formulation and its solution 
based on back-pressure. A linear optimization framework for 
packing butterflies is proposed in l20l . 

Compared to prior NUM problems in coded networks, we 
focus on the congestion control problem for multiple unicast 
flows over wireless with a given inter-session network coding 
scheme. The most similar formulation is (9), but for intra- 
session network coding. 

Protocol design. To the best of our knowledge, our work 
is the first, to take the step from theory (optimization) to 
practice (protocol design), specifically for the problem of 
congestion control over inter-session network coding. We 
propose implementation changes, which have a number of 
desired features: they are justified and motivated by analysis, 
they perform well (double the throughput in simulations), and 
they are minimal (only queue management is affected, while 
TCP and MAC remain intact). 

Comparison to our prior work. This paper is an improved 



and extended version of our conference paper that was pre- 
sented in NetCod 2010 125) , It includes significantly extended 
sections on simulations of performance (Sections VI and VII) 
as well as new numerical results on the convergence (Appendix 
A) of our schemes. It also extends the framework from one- 
hop to multi-hop network coding (Section VII). 

In another piece of recent work |24) . we studied a related but 
orthogonal aspect: we added intra-session redundancy to inter- 
session network coding in order to deal with wireless losses 
and to eliminate the need to know the state of the neighbors. In 
contrast, in this paper we consider only inter-session coding 
and we focus on the interaction between local (coding and 
queue management) and end-to-end (TCP) schemes, which 
was out of the scope of |24) . 

III. System Model 

Sources/Flows. Let S be the set of unicast flows between 
some source-destination pairs. Each flow s £ S is associated 
with a rate x s and a utility function U s (x s ), which we assume 
to be a strictly concave function of x s . The goal is to maximize 
the total utility function Ut = YlseS Us(%s)- 

Wireless Network. A hyperarc (i, J) is a collection of 
links from node i G Af to a non-empty set of next-hop nodes 
J C Af that are interested in receiving the same network 
code through a broadcast transmission from i. A hypergraph 
H = (Af, A) represents a wireless mesh network, where Af is 
the set of nodes and A is the set of hyperarcs. For simplicity, 
h = (i, J) denotes a hyperarc, h(i) denotes node i and h(J) 
denotes node J, i.e., h(i) = i and h(J) = J . We use these 
terms interchangeably in the rest of the paper. 

Due to the shared nature of the wireless media, transmission 
over different hyperarcs may interfere with each other. We 
consider the protocol model of interference lET) . according 
to which, each node can either transmit or receive at the 
same time and all transmissions in the range of the receiver 
are considered as interfering. Given a hypergraph H, we can 
construct the conflict graph C = (A,I), whose vertices are 
the hyperarcs of H and edges indicate interference between 
hyperarcs. A clique C q C A consists of several hyperarcs, 
at most one of which can transmit at the same time without 
interference. 

Network Coding: We assume that intermediate nodes use 
COPE Q] for one-hop opportunistic network coding^. Each 
node i listens all transmissions in its neighborhood, stores 
the overheard packets in its decoding buffer, and periodically 
advertises the content of its decoding buffer to its neighbors. 
Then, when a node i wants to transmit a packet, it checks or 
estimates the contents of the decoding buffer of its neighbors. 
If there is a network coding opportunity, the node combines 
the relevant packets using simple coding operations (XOR) and 
broadcasts the combination to J . Note that it is possible to 
construct more than one network code over a hyperarc (i, J). 
Let Ki,j be the set of network codes over a hyperarc (i, J). 
Let Sk C S be the set of flows, whose packets are coded 
together using code k G and broadcast over (i, J). 

Routing: We consider that each flow s G S follows a single 
path V s C Af from the source to the destination. This path is 

1 Note that we present the multi-hop extension in Section I VIII 
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Fig. 1. "X topology". Source Si transmits a flow with rate x\ to receiver 
Rl and source S2 transmits a flow with rate X2 to receiver R2, over the 
intermediate node /. A\ and Bi transmit their packets a and b, in two 
time slots, and node / receives them. Furthermore, A2 overhears b and B2 
overhears a, because A\ — B2 and B\ — A2 are in the same transmission 
range and they can overhear each other. In the next time slot, / broadcasts the 
network coded packet, a©fe over hyperarc (/, {A2, B2}). Since A2 and B2 
have overheard b and a, they can decode their packets a and b, respectively. 

pre-determined by a routing protocol, e.g., OLSR or AODV, 
and given as input to our problem. However, note that several 
different hyperarcs may connect two consecutive nodes along 
the path. We set an indicator function H\'j = 1 if flow s is 
transmitted through hyperarc (i, J) using network code k G 
ICi.j. Otherwise, H?'j = 0. 

Example 1: The example shown in Fig. [T] illustrates the 
problem we consider. Since / can transmit a © & in one 
time slot, instead of a, b in two time-slots, network coding 
has the potential to improve throughput. However, if there is 
mismatch between the rates £1,2:2 of the two flows, / may 
not have packets from the two flows to code together at all 
times, and thus does not exploit the full potential of network 
coding. We confirmed this intuition through simulations in this 
example topology. When the buffer size was set to 10 packets 
at each node and the bandwidth was 1Mbps for each link, we 
observed that 50% of the time, there were no packets from 
the two flows at the same time at node I to code together. 
For smaller queue sizes and larger transmission rates, there 
were even fewer coding opportunities. This means that there 
is potential for improvement by updating the protocols so as 
to mitigate the rate mismatch between TCP flows. This is the 
observation that motivates this paper. □ 

IV. Optimal Congestion Control 

A. Problem Formulation 

The objective is to maximize the total utility function, by 
appropriately selecting: the flow rates x s at sources s G S; 
their traffic splitting parameter a s h ,k (following the terminology 
of J9)) into network codes k G ICh over hyperarc h at inter- 
mediate nodes; and the percentage of time r/j each hyperarc 
is used: 

max > U s (x s ) 
ses 

s.t. ma.x{H^' k a s ^ k x s } < RhTh, Vft G A 

E E a 8 H k = l,VseS,i€V s 
h{j)\heAkeic h \ses k 

E T h< r, VC„ C A (1) 

hec q 



The first constraint is the capacity constraint. H^ k a s h ,k x s 
indicates the part of flow rate x s allocated to the fc-th network 
code over hyperarc h. The rate of the fc-th network code is 
the maximum rate among flows s G <Sfc coded together in 
code k: max se s fe {iJ?' a?' J8]. Different network codes 
k G ICh over h share the available capacity RhTh, where Rh 
is the transmission capacity of h; since ft, is a set of links, 
Rh is the minimum: Rh = mmj £ h(j){Ri.j£.i.j} where Rij 
is the capacity of link and £jj is the probability of 

successful transmission over link The second constraint 

is the flow conservation constraint: at every node i on the path 
V s of source s, the sum of a h ,k over all network codes and 
hyperarcs should be equal to 1. Indeed, when a flow enters 
a particular node i, it can be transmitted to its next hop j 
as part of different network coded and uncoded flows. The 
third constraint is due to interference. As mentioned, r/j is the 
percentage of time h is used. Its sum over all hyperarcs in a 
clique should be less than an over-provisioning factor, 7 < 1, 
because all hypearcs in a clique interferes, and should time 
share the medium. 

B. Solution 

By relaxing the capacity constraint in Eq. (Q~|i, we get the 
Lagrangian: 

L(x, a, t, q) = 

E U »( x s) ~ E qh ( E ]™?{ H h ka h kx s} ~ R hn. ] 
ses heA \keK h k / 

(2) 

where qh is the Lagrange multiplier, which can be interpreted 
as the queue size at hyperarc h, as discussed later. To decom- 
pose the Lagrangian, we rewrite m&x se s k {H h uk a s ^ k x s } as 

E TT s.k s,k s,k . s.k 1 1 

ses k H h a h x ° m h S - L T, se s k m h = L where 

m h ,k is a new variable, which we call the the dominance 

indicator. It indicates whether the source s has the maximum 

rate among all flows coded together in the fc-th network code, 

or not. In the next section, we will see that only the dominant 

flow in a network code needs to back-off during congestion. 

The Lagrange function in Eq. (f2]i is not strictly concave in 

s k 

rriu and this causes oscillation in its solution. We use the 
proximal method l22l to eliminate oscillations; 

E, TT s,k s.k s.k 1 s.k s,k\2\ 

( H h a h x s m h - c K m h -»h)) 

ses k 

s.t. E m h k = !) ( 3 ) 

s£S k 

where c is a constant and fi^ k is an artificial variable of the 
proximal method J22). Its value is set to m s ^ k periodically. 
Let (m s ^ k )* be the solution to this problem. 

By rewriting the summation J2keic h S s es fc as 
E se< s EkeK h \ses k > the Lagrange function in Eq. © 
can be expressed as: L(x,a,T,q) = J2heA ( l hRhTh + 

Eses ( c/ »( a? »)- a! «Eh6xX)fcex:fc|.€S* fl^fc* '"h* '("#*)*) ■ 
Now, we can decompose the Lagrangian into the following 
intuitive problems: rate control, traffic splitting, scheduling, 
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and parameter update (queue management). 

Rate Control. First, we solve the Lagrangian w.r.t x s : 

\h£AkGK. h \s<£S k J 

where (l^) -1 is the inverse function of the derivative of 
U s . If we define w s h = T,ke)C h \seS k ^a*"/,* (»#*)* and 
1h(i) = Sfc^lhe^Sfe^. the rate x s can be expressed as 
x s = (U' s )~ 1 (J2 tePs q*), noting that i = h(i). 

In the special case where proportional fairness is desired, 
Us(x s ) = log(x s ),Vs G S, leading to x s = (2 ie -p o qf) , 
i.e., x s is inversely proportional to the total network coded 
queue sizes over the path of flows s, which we will be 
explained later. 

Traffic Splitting. Second, we solve the Lagrangian for ot h ,k : 
at each node i along the path {i.e., i G V s ), the traffic splitting 
problem can be expressed as 

\ * \ ^ JT s.kf s,k\* s,k 

7 L 1^ qhH h ( m h ) a h 

h(.J)\heAk£K h \seS k 

s.t. E E a h k = !' Vi e ^ (5) 

k(j)|he»4fceJ0»|ses A , 

Similarly to Eq. (0, we also use the proximal method l22l to 
solve the optimization problem in Eq. (0. 

Scheduling. Third, we solve the Lagrangian for Th- This 
problem is solved for every hyperarc and every clique in the 
conflict graph in the hypergraph. 

max E IhRhTh 

heA 

s.t. E T h < t, VC q C A. (6) 

/tgC, 

Parameter (Queue Size) Update. We find q h , using 
a gradient descent algorithm: qh(t + 1) = {qh(t) + 

Ct[Y,keK h T,ses k H h ka h k ( m h k T x - ~ RhT h ]}+. Equiva- 
lently; 

q h (t + 1) = {qh(t) + c t [ E vaB:yi { H h ka h kx s} ~ RhTh]} + 

(7) 

where t is the iteration number, ct is a small constant, and the 
+ operator makes the Lagrange multipliers positive, qh can be 
interpreted as the queue size at hyperarc V7i G A. Indeed, 
in Eq. (0, is updated with the difference between the 
incoming }~2 keKh max s£S k {H^' k a s h ' k x s } and outgoing R h T h 
traffic at h. Therefore, we call qh the hyperarc-queue, or h- 
queue for brevity. We confirmed the convergence of qh's via 
numerical calculations as seen in Appendix A. 

V. Network Coding- Aware Implementation 

In the previous section, we saw that the NUM problem 
decomposed into Eq. (0, Eq. (0, Eq. ©, Eq. ©, each of 
which has an intuitive interpretation. In this section, we mimic 
the properties of the optimal solutions to these problems and 
propose modifications to the corresponding protocols to make 
them network coding-aware. It turns out that only changes to 



queue management at intermediate nodes are crucial, while 
TCP and scheduling can remain intact. This makes our pro- 
posal amenable to practical deployment. 

A. Queue Management at Intermediate Nodes (NCAQM) 

1 ) Summary of Proposed Scheme: We refer to our Net- 
work Coding-Aware Queue Management scheme as NCAQM. 
NCAQM builds on and extends COPE 0]. Its goal is to 
interact with TCP congestion control in such a way that 
it matches the rates of TCP flows coded together and thus 
increases network coding opportunities. It achieves this goal 
through the following minimal changes at intermediate nodes. 
First, NCAQM stores coded packets in the output queue Qi, 
as opposed to COPE that stores uncoded packets. Second, 
NCAQM maintains state per hyperarc queue qh and per 
network code transmitted over each hyperarc k G fCh', this is 
feasible in the setting of wireless mesh with limited number of 
flows. Third, during congestion, packets are dropped from the 
flow that has the largest number of packets, where this number 
is computed only over h-queues where the flow is dominant. 
Consider several flows coded together in the same code: the 
rate of the dominant flow is the rate of the code; and dropping 
from the dominant flow matches the rates, as desired. We note 
that intermediate nodes do already network coding operations 
and can be naturally extended to implement these changes. 

2) Detailed Description of Proposed Scheme: 
Maintaining Queues: In Q], a wireless node i stores 

all packets uncoded in a single output queue Qi and takes 
decisions at every transmission opportunity about whether to 
code some of these packets together or not. In contrast, we 
propose to network code packets, if an opportunity exists, 
at the time we store them in the queue. Motivated by the 
fact that Lagrange multiplier (h-queue) qh in Eq. (0 can be 
interpreted as the queue size at hyperarc h, we maintain h- 
queue virtualljH for each hyperarc at every node, which keeps 
track of packets that are network coded and broadcast over 
h. The size of an h-queue is Qh and how it is determined in 
practice will be explained later. Each node i maintains a single 
physical output queue, Qi, which stores all packets (coded and 
uncoded depending on the opportunities) passing through it. 

Network Coding (Alg. 1): Motivated by the fact that the 
incoming traffic in Eq. (0 is the sum of the network coded 
flows over h, we code packets when they are inserted to output 
queues. If a network coding opportunity does not exist when 
the packet arrives at node i, we just store it in Qi in a FIFO 
way. Periodically, Alg.0runs to check all packets in the queue 
for network coding. 

Let Qi = {pi,p2, ...,pi} where p\ is the first and pi 
is the last packet in the queue; / < L, where L is the 
buffer size, i.e., the maximum number of packets that can 
be stored in Qi. First, p\ is picked for network coding. Since 

-We maintain a virtual, not a physical, h-queue, because the latter would 
be difficult in practice: (i) the total buffer size is limited and allocating it to 
h-queues is another control parameter; (ii) h-queues may change over time 
depending on changes in the topology and traffic scenario; (iii) storing packets 
in h-queues may reduce network coding opportunities in a packet-based 
system (although it is optimal in a flow-based system) due to opportunistic 
network coding. 
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Algorithm 1 Network coding in output queue Qi at node i 

1: for m = 1...L do 

2: if 3p m 6 Qi then 

3: for n = (m + 1)...L do 

4: if p m © p n is eligible then 

5: Pm «- Pm ©p™ 

6: end if 

7: end for 

8: end if 

9: Update Q; 

10: end for 



Algorithm 2 Packet dropping at node i during congestion 

1: Initialization: <I>f = 0, Vs G 5, 5- = 

2: if 2 > L then 

3: for Vs G S do 

4: Calculate <S>| = Eh(j)|h G ^ 

5: end for 

6: S t = argmax seS {$f} 

7: Choose a flow s' G S i randomly 

8: if 3p n G Qi, n = 1.1, from flow s' then 

9: Drop p n 

10: else 
1 1 : Drop pi 

12: end if 

13: end if 



Qi stores network coded packets, p\ may be already coded. 
Independently of whether p\ is network coded or not, it can be 
further coded with other packets in the queue beginning from 
P2, if the following two conditions are satisfied; (i) the packets 
constructing p\ and pi should be from different flows, and (ii) 
Pi ®P2 should be decodable at the next hop of all packets that 
construct the network code. If these conditions are satisfied, 
we say that the network code is an eligible network code, and 
Pi is replaced by p\ ®pi- Then p\ ®P3 is checked for network 
coding, etc. After all packets are checked for network coding, 
the output queue Qi is updated: (i) the final packet p\ is 
stored in the first slot of the output queue, and (ii) the memory 
allocated to other packets are freed. Then, the same algorithm 
is run for packet p2, etc. When a transmission opportunity 
arises, the first packet from the output queue is checked for 
network coding again and broadcast over the hyperarc. 

Let the number of packets from flow s in node i be Qf . Qf 
captures the difference between the incoming and outgoing 
traffic for flow s at node i. Since an h-queue captures the 
difference between the incoming and outgoing traffic over a 
hyperarc, we calculate its size using the following heuristic: 

Qh = Y^k£K h max s£s k { H h k °<h k Qi}> where & h k is the 

approximate traffic splitting, explained next. 

The traffic splitting parameters ct h ,k are found through 
the optimization problem in Eq. (0. Through numerical 
calculations, we made the following observation: each a^ k 
converges to the percentage of time that packets from flow s 
are transmitted with the fc-th network code over h at node i. 
At each packet transmission, we calculate the probability that 
a network code k over hyperarc h can be used for flow s, over 
a time window. The average calculated over this window gives 
a heuristic estimate of the traffic splitting parameter, a^ k . 

Packet Dropping (Alg. 2): When a node is congested, 
it decides which packet to drop. In order to eliminate the 



potential of rate mismatch between flows coded together, we 
propose that the node compares the number of all (coded and 
uncoded) packets of each flow, in queues where the flow is 
dominant (mj = 1). This is motivated by the optimal rate 
control in Eq. More specifically, for each flow s, we 
calculate $f = Y,h(j)\heAQhW s h , where w s h = EkeK h \seS k 
and H^ k a s h ,k rh s ^ k . Upon congestion, the $f's are compared 
and a packet from the flow with the largest is dropped, 
preferably the last uncoded packet. The choice of the last 
packet is to make it similar to DropTail. The choice of uncoded 
packet is so as to hurt only one flow, as opposed to several. If 
there is a tie in the $'s between flows, one flow is randomly 
picked to drop a packet. If all packets from the selected flow 
are coded, a new coming packet(s) is dropped instead. 

To estimate the dominance indicator rh 3 ^ needed in Alg. 12 
we compute heuristically an estimate to?' as follows. If 
H^afQf < H(> k a(> k Qj' s.t. 3s' e S k {>}. then 
m% k = 0. Otherwise, m,; k = (IS^I) -1 where S£ iax = 
{s\s eS k A H^afQI = nmx{H s ^ k a(' k Q! | s' e S k }}. 

B. Rate Control at the Sources 

For logarithmic utility, we saw that the optimal rate control 
in Eq. (01 is x s = {^2 ieV if) 1 - qf corresponds to the length 
of the network coded queue size of flow s at node i. The 
optimal rate x s is inversely proportional to the sum of these 
queue sizes q* across all nodes i on its path V s . This is 
essentially a generalization of standard optimal rate control 
ID, to account for network coding in the calculation of queue 
sizes. 

When rate control is implemented, it is impractical to 
feed back to the source the full information J2iev it' as 
required by the optimal control. Instead, when a queue is 
congested, a packet is dropped or marked B. The source 
uses this binary information as a signal to reduce its rate, 
mimicking the inverse relationship in the optimal control. 
The exact adaptation of the flow rate depends on the TCP 
version used. In the simulations, we used TCP-SACK without 
any modification. The only change we propose is the packet 
dropping scheme at the queue (Alg. 2), to take into account 
not only congestion but also network coding. Essentially, TCP 
still reacts to drops but these drops are caused when the flow 
is dominant in at least one network coded queue along the 
path. 

Example 2: Let us re-visit the example in Fig. [T] There is 
only one network coded flow over h = (I, {^2,-62}) and 
assume that link transmission rates are the same. Then the 
two flows are always coded together and their traffic splitting 
parameters approach to 1. The network coded queue sizes are 
&i = QhTnji and <£>f = Q^to^, where Qh is the size of 
the h-queue for h = (I, {A2, B2}), and fh h and fh\ are the 
dominance indicators for the two flows. Since Qh is constant, 
$}, $| depend on rh h and m^, i.e., on which flow has more 
packets in the output queue. Upon congestion, a packet from 
the first is dropped if it has more packets in the queue. Then, 

51 will reduce its rate by transmitting less packets, while flow 

52 keeps increasing its rate, thus decreasing the probability 
that there is no packet from the second flow for coding at node 
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Fig. 3. Grid topology. Multiple unicast flows Si — Ri, S2 — R2, etc., 
meeting at different intermediate points. 

/. More generally, the interaction of our queue management 
(NCAQM) mechanism and TCP tends to eliminate the rate 
mismatch of the flows coded together. □ 

C. Scheduling 

The scheduling part in Eq. (|6]l has two parts: intra- and 
inter-scheduling that determine which packet to transmit from 
a node and which node should transmit, respectively. Both 
have difficulties in practice. Intra-scheduling causes packet 
reordering at TCP receivers. Inter-scheduling requires central- 
ized knowledge and it is NP hard and hard to approximate J5) . 
Given these difficulties and our original goal to make minimal 
changes to protocols related to congestion control, we limit our 
proposed modifications to the queue management. We do not 
propose new scheduling and we use FIFO scheme for packet 
transmission and standard 802.11 as wireless MAC. 

VI. Performance Evaluation 

In this section, we evaluate the throughput of TCP over our 
proposed scheme (NCAQM) in various topologies and traffic 
scenarios. We compare it to TCP over the following baseline 
schemes: no network coding (noNC), which uses FIFO without 
network coding; COPE (TJ, which stores native packets in 
a FIFO and decides which packets to code together at each 
transmission opportunity; and the optimal control. 

A. Simulation Setup 

We used the GloMoSim simulator 0231 . which is well suited 
for wireless. We implemented from scratch the modules for 
one-hop network coding over wireless mesh networks (COPE) 
as well as for our proposed scheme (NCAQM). 

1) Topologies: We simulated four illustrative topologies 
shown in Fig. Q] Fig. [2] and Fig. [3] In X and Alice-and- 
Bob topologies, shown in Fig. Q] and Fig. |2ja), two unicast 
flows Si — Ri and 52 — R2 meet at intermediate node /. 
In the cross topology, shown in Fig. 12b), four unicast flows 
S1 — R1, S2 — R2, S3 — i?3, and S4 — R4 are transmitted via the 
relay /. In the wheel topology, shown in Fig. |2jc), multiple 
unicast flows such as Si — Ri, S2 — R2, S3 — R3, S4 — R4, 
and etc. are combined at the intermediate node I. Note that the 
wheel topology is the generalized version of the cross topology 
shown in Fig.|2b). In all these topologies node /; (i) performs 
network coding, and (ii) is placed in the center of a circle with 



90m radius over 200m x 200m terrain and all other nodes 
are placed around the circle. Finally, we considered the grid 
topology shown in Fig. [3] in which nodes are distributed over 
a 300m x 300m terrain, divided into 9 cells of equal size. 15 
nodes are divided into sets consisting of 1 or 2 nodes and each 
set is assigned to a different cell. Nodes in a set are randomly 
placed within their cell. If both the transmitter and the receiver 
are in the same cell or in neighboring cells, there is a direct 
transmission; otherwise, a node in a neighboring cell acts as 
a relay. If there are more than one neighboring cells, one is 
chosen at random. In all topologies, a single channel is used 
for both uplink and downlink transmissions. 

2) MAC: In the MAC layer, we simulated IEEE 802.11 
with RTS/CTS enabled and with the following modifications 
for network coding. First, we need a broadcast medium, 
which is hidden by the 802.11 protocol. We used the pseudo- 
broadcasting mechanism of (TJ: packets are XOR-ed in a 
single unicast packet, an XOR header is added for all nodes 
that should receive that packet, and the MAC address is set to 
the address of one of the receivers. A receiver knows whether 
a packet is targeted to it from the MAC address or the XOR 
header. 

3) Wireless Channel: We used the two-ray path loss model 
and Rayleigh fading in Glomosim. We set the average loss 
rate to 15%. In our simulations 15% loss rate is medium loss 
rate, and residual loss rate after MAC re-transmissions is less 
than 1%0 

4) TCP Traffic: We consider FTP/TCP traffic on top of the 
wireless network. In the Alice-and-Bob, X, cross, and wheel 
topologies, TCP flows, between the pairs of nodes described 
above, start at random times within the first 5sec and live 
until the end of the simulation. In the grid topology, TCP 
flows arrive according to a Poisson distribution with average 
6 flows per 30sec. The sender and the receiver of a TCP flow 
are chosen randomly. If the same node is chosen, the random 
selection is repeated. 

B. Simulation Results 

In this section, we present simulation results for the Alice- 
and-Bob, X, cross, wheel, and grid topologies. We compare 
to: (i) TCP over NCAQM (TCP+NCAQM), (ii) TCP over 
COPE (TCP+COPE), (iii) the optimal solution (optimal rate 
control in Eq. working together with the optimal queue 
management in Eq. (|7]i). We report the average throughput 
of each scheme as % improvement over the throughput of 
the baseline TCP+noNC. In addition, we report transport level 
throughput. All throughput results reported in this section are 
averaged over Imin simulation duration first, then over 10 
simulations with different seeds. 

Table H] presents the results for the following parameters: the 

3 When channel loss rate increases, there are two problems. First, the 
residual loss rate after MAC re-transmissions increases. Therefore, TCP is 
not able to utilize the medium effectively and benefit of network coding 
reduces. Second, network coding decision at intermediate nodes becomes 
erroneous, because intermediate nodes do not know which packets are 
overheard correctly. These issues are out of scope of this paper, and we have 
analyzed them separately in 1241 . 
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Fig. 2. (a) Alice-and-Bob Topology. Two unicast flows, Si — ill, and S2 — i?2, meeting at intermediate node I. (b) Cross topology. Four unicast flows, 
Si — ill, S2 — R2, S3 — i?3, and S4 — R4, meeting at intermediate node /. (c) Wheel topology. Multiple unicast flows Si — ill, S2 — i?2, etc., meeting 
at intermediate node I. I opportunistically combine the packets and broadcast. 



buffer size at each intermediate node is 10 packet^ the packet 
size is 5005; the channel capacity is 1Mbps. In this scenario, 
TCP+NCAQM has two advantages: (i) it stores network coded 
packets instead of the uncoded ones, thus uses the buffer more 
effectively, and (ii) it drops packets so that network coding 
opportunities increase. Thus, our scheme (TCP+NCAQM) 
significantly improves throughput as compared to TCP+COPE 
in all four topologies. It is also seen from the table that 
there is still a gap between our scheme and the optimal 
improvement due to the very limited buffer size for multiple 
flows at the relay. Yet, even in this challenging scenario, 
TCP+NCAQM significantly improves over TCP+COPE: it 
doubles the throughput improvement of TCP+COPE. 

In Table HI the improvement of TCP+NCAQM and 
TCP+COPE in Alice-and-Bob topology is slightly smaller 
as compared to X topology, although Alice-and-Bob and X 
topologies have the same optimal improvement (33%). In 
Alice-and-Bob topology, source nodes are also receiver nodes, 
i.e., Si — R2 and S2 — Ri pairs are the same nodes; Ax, A<z, 
respectively. Therefore, transport level data and ACK packets 
share the same buffers at these source/receiver nodes. Due 
to the limited buffer size, some packets are dropped at the 
source/receiver nodes, and this reduces TCP throughput. It is 
also seen that the improvement in cross and grid topologies is 
larger as compared to Alice-and-Bob and X topologies, for the 
following reasons: (i) in cross topology, four flows (i.e., four 
packets) are combined at the intermediate node (/) instead of 
two flows, and (ii) in grid topology, we have observed that, 
during a part of lmin simulation duration, four or more flows 
are combined at intermediate nodes. 

Fig. @] presents the cumulative distributed function (CDF) 
of throughput improvement for the Alice-and-Bob, X, cross, 
and grid topologies and the same setup. The CDFs are 
calculated over 30 seeds. One can see that the CDF of 
TCP+NCAQM is shifted to significantly higher throughput 
levels compared to TCP+COPE in all four topologies. For 
example, TCP+NCAQM improves the throughput more than 
20% and 40% in more than 60% of the realizations in Alice- 

4 Note that 10 packet buffer size corresponds to bandwidth-delay product 
(BDP) in our simulation scenario. We also present simulation results for larger 
buffer sizes later in this section. 



TABLE I 

Average throughput improvement compared to noNC. 





Optimal 


TCP+NCAQM 


TCP+COPE 


Alice-and-Bob Topology 


33% 


18% 


8% 


X Topology 


33% 


19% 


9% 


Cross Topology 


60% 


39% 


21% 


Grid Topology 




35% 


18% 



and Bob and cross topologies, respectively. In contrast to 
Alice-and-Bob and cross topologies, we also observe that 
the CDF of TCP+NCAQM is shifted to higher throughput 
levels compared to the CDF of TCP+COPE in the cross 
and grid topologies. In the cross and grid topologies, it is 
possible to code more than two flows together, and when 
the number of flows coded together increases, the way that 
TCP+NCAQM uses buffers and balances the rates becomes 
more important. Thus, we see larger improvement in the cross 
and grid topologies. 

Fig. [5] shows the average transport-level throughput versus 
the buffer size, for the Alice-and-Bob, X, cross, and grid 
topologies. Packet size is 500-B, and channel capacity is 
1Mbps. Our observations from Fig. [5] are in the following. 

The throughput improvement of TCP+noNC for different 
buffer sizes is negligible in all topologies. The reason is 
that 10 packet buffer size is already matched to bandwidth- 
delay product (BDP) and TCP utilizes wireless medium ef- 
fectively for almost all buffer sizes when network coding is 
not used (TCP+noNC). However, for network coding schemes 
(TCP+NCAQM and TCP+COPE), the throughput increases 
significantly with increasing buffer size. This shows the im- 
portance of active queue management in coded networks. 

When buffer sizes are small, the improvement of 
TCP+NCAQM over TCP+noNC is significantly larger than 
that of TCP+COPE. This is for the same reason explained 
earlier: TCP+NCAQM stores network coded, instead of un- 
coded packets, thus using buffer more effectively, and it drops 
packets so that network coding opportunities increase. Thus, 
our scheme (TCP+NCAQM) significantly improves through- 
put as compared to TCP+COPE in all four topologies. 

The throughput of TCP+COPE increases when buffer sizes 
increase, which is intuitively expected. The problem addressed 
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Fig. 4. Cumulative distribution function (CDF) of throughput improvement for Alice-and-Bob (shown in Fig. [2ja)), X (shown in Fig. [T}, cross (shown in 
Fig. |2Jb)), and grid (shown in Fig. [5} topologies. Buffer size is 10 packets, packet sizes are 500-B, and the channel capacity is 1Mbps. The distributions are 
generated over 30 seeds. 



in this paper was the mismatch between rates of flows coded 
together, due to the bursty nature of TCP, which reduces 
coding opportunities. However, when buffer sizes increase, 
there are more packets available in queues for coding. Thus, 
TCP+COPE exploits coding opportunities at larger buffers 
and its throughput increases. However, even at the large 
buffer sizes, TCP+NCAQM improves throughput more than 
TCP+COPE. For example, TCP+NCAQM improves through- 
put 7% more than TCP+COPE in X topology when buffer 
size is 50 packets. Fig. [5] demonstrates that our scheme is 
particularly beneficial in harsh buffer size conditions. 

The improvement of TCP+NCAQM over TCP+noNC ex- 
ceeds the optimal throughput at some buffer sizes. E.g., the 
improvement of TCP+NCAQM over TCP+noNC is around 
40% in the X topology when the buffer size is set to 30 packets 
(although the optimum improvement is 33%). The reason is 
that since TCP+NCAQM uses the buffer more effectively by 
storing network coded packets instead of uncoded packets, 
TCP can utilize the medium more effectively, thus the TCP 
rate increases beyond the network coding benefit. 

Fig. [6] shows the average transport-level throughput versus 
the number of flows in the wheel topology shown in Fig. |2c). 
The buffer size is 30 packets, the packet size is 500B, and 
channel capacity is 1Mbps. One can see from the figure that 
the throughput of TCP+noNC reduces with increasing number 
of flows. This is expected, because when the number of flows 
increases, all flows share the same queue at the intermediate 
node /. As a result, the round trip time of each flow increases, 
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Fig. 6. Average throughput (averaged in lmin simulation first, then over 
10 seeds) versus the number of flows in wheel topology shown in Fig. |5Jc). 
Buffer size is 30 packets, packet size is 500B, and the channel capacity is 
1Mbps. 

and thus the TCP rate decreases. On the other hand, the 
throughput of TCP+NCAQM and TCP+COPE increases with 
the number of flows, because when the number of flows 
increases, there are more network coding opportunities and 
more packets can be combined together (i.e., it is possible 
to combine 8 packets when the number of flows is 8). 
TCP+NCAQM significantly improves over TCP+COPE for all 
number of flows, especially when the number of flows is large. 
This is intuitive, because when the number of flows increases, 
network coding opportunities increases, and TCP+NCAQM 
exploits these opportunities effectively. 

Fig.Qpresents the average transport-level throughput versus 
channel capacity for the Alice-and-Bob, X, cross, and grid 
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Fig. 5. Average throughput (averaged in train simulation first, then over 10 seeds) versus buffer size for Alice-and-Bob (shown in Fig. |2ja)), X (shown in 
Fig. [T}, cross (shown in Fig.|5Jb)), and grid (shown in Fig. [3} topologies. Packet size is 500-B, and channel capacity is 1Mbps. 



topologies. The buffer size is 30 packets, and the packet 
size is 500-B. One can see from the figure that when the 
channel capacity increases, the gap between TCP+NCAQM 
and TCP+COPE increases. Therefore, while the improvement 
of TCP+NCAQM over TCP+noNC increases with increasing 
channel capacity, it decreases for TCP+COPE. Namely, the 
improvement of TCP+NCAQM increases from 40% to 42%, 
while the improvement of TCP+COPE decreases from 27% to 
16% in X the topology. The improvement of TCP+NCAQM 
is quite significant; more than double the improvement of 
TCP+COPE at 11Mbps channel capacity. The reason is that 
when the channel capacity increases, more packets share 
buffer at intermediate node. TCP+NCAQM can improve the 
throughput by using the shared buffers more effectively, and 
by dropping packets so as to increase network coding oppor- 
tunities. 

VII. Multi-Hop Network Coding 

In this section, we extend our framework from one-hop to 
multi-hop network coding. We note that our framework can 
accommodate any given multi-hop network coding scheme, 
but we use BFLY in our simulations, as an example. 

A. System Model 

We consider the same system model as in Section [Till with 
the difference of multi-hop, as opposed to one-hop, network 
coding. A flow s can be network coded and decoded several 
times over its path V s . The network coded flow may be 



transmitted over multiple (M) hops, which we call A/-hop 
network coding. M-hop network coding is implemented by 
COPE 0] for M = 1, BFLY © for M = 2, or other 
network coding schemes for M > 2. We assume that a flow 
s cannot be network coded if it (or a part of it) is already 
coded. This assumption allows us to divide the path V s to F s 
intermediate paths which we call network coding paths. Over 
its f-th network coding path, where / G {1, . . . , F s }, flow s 
can be network coded with Tj G {0, 1, . . . , \S — {s}\} other 
flows. Without loss of generality, we can assume that a flow 
may be transmitted over the /-th network coding path without 
network coding; i.e., Tj = 0. A flow s can be divided into 
network coded and non-network coded parts over a network 
coding path /, where Z{ is the set of partitions of flow s 
over its f-th network coding path. Each partition z G Z[ 
transmitted over hyperarc h has one-to-one mapping with the 
fc-th network code over h such that k G Kh, '•<?., z = r/(k) 
over h where rj is an injective function. 

Example 3: The example shown in Fig. [8] illustrates the 
problem with 2-hop network coding. The flow from source Si 
is transmitted over the link A\ — I\ without network coding 
and it is network coded over the links l\—l<i and /2 — ^2- Over 
the network coding path, including the set of nodes I\, I2, A2, 
the flow rate x\ is partitioned into a network coded and a non- 
network coded part. The network coded part is combined with 
the corresponding part of the flow from source S2, transmitted 
over 1\ — I2, and broadcast over (I2, {A2, -B2}). The other 
part is transmitted over 1\ — I2 and I2 — A2 without network 
coding. Similar to the one-hop network coding in Example [TJ 
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Fig. 7. Average throughput (averaged in lmin simulation first, then over 10 seeds) versus channel capacity for Alice-and-Bob (shown in Fig. [2]a))> X 
(shown in Fig. [T}, cross (shown in Fig. |2jb)), and grid (shown in Fig. [5J topologies. Buffer size is 30 packets, and packet size is 500B. 




a + b 



Fig. 8. "Butterfly topology". Source Si transmits a flow with rate xi to 
receiver R± and source S2 transmits a flow with rate X2 to receiver R2, over 
the intermediate nodes I\ and 12- Nodes A\ and B\ transmit their packets 
a and b, in two time slots, and node I\ receives them. Node B2 overhears 
a and A2 overhears b, because A\ — B2 and B\ — A2 are in the same 
transmission range and they can overhear each other. In the next time slot, I\ 
transmits the network coded packet a © b to node 12- Finally, I2 broadcast 
a(£)b over hyperarc (I2, {A2, S2}). Since A2 and B2 have overheard b and 
a, they can decode their packets a and b, respectively. 



if there is a mismatch between the rates xi,X2 of the two 
flows, network coding benefit is not fully exploited. The goal 
is to solve this problem, assuming a given multi-hop network 
coding scheme. □ 



B. Problem Formulation 

We consider the following NUM problem; 

max U s (x s ) 

x,a,T — ' 

s.t. max{iJ^ fc Q!^ fc a; s } < RhVi: V h e A 

Y, /3/ ,z = l, V seS,f = l,...,F s 

s , k _ \(3 s f '\ 3 z = V (k), z e Zfj = 1, F s 
1 0, otherwise. 

^r^r, VC,Ci (8) 
hec q 

The NUM problem in Eq. (© is similar to the one in Eq. 
in terms of the objective functions, capacity and interference 
constraints. We only need to update the flow conservation 
constraint (the second constraint) and add the third constraint, 
as explained below. 

We introduce a new traffic splitting parameter /3f' z which 
represents the percentage of the flow rate x s allocated to the 
z-th partition of flow s over its /-th network coding path. The 
traffic splitting parameters should sum up to 1 according to the 
flow conservation constraint over each network coding path 
(the second constraint). Since there is a one-to-one mapping 
between the z-th partition and the fc-th network code over 
h, the traffic splitting parameters, a s ^ k and 0*' z should be 
equal (the third constraint). This also implies the following 
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equalities; H'* = H> h >>, mf = m' h * 
C. Solution 

We use Lagrangian relaxation to solve the optimization 
problem in Eq. ^ by relaxing the capacity constraint with 
Lagrange multipliers q^. We obtain the same Lagrange func- 
tion in Eq. (f2]). The Lagrange function is decomposed into the 
same subproblems as in Eq. Q, Eq. ©, Eq. (0 and Eq. ||7). 
The only different subproblem is the traffic splitting problem, 
which can be expressed as 

1^ 9h H h a h K m h ) 

heAk£K h \seS k 

s.t. ]T F/' = l, VsG5,/ = l F, 

zez£ 

s, k if/*, 3z = V (k),zeZiJ = l,...,F s 
a h = < 1 (9) 
I 0, otherwise. 

The objective function in Eq. (O can be expanded to be 

£/=i EheAf Ekeic h \ses k 9fc#h where A f is 

the set of hyperarcs that originate from the nodes in the f-th 
network coding path of flow s. The two objective functions are 
equivalent considering the fact that the objective function in 
Eq. © is equal to zero for hyperarcs which are not originated 
from the nodes over the flow's network coding paths, because 
the indicator functions (H^ k ) are zero for those hyperarcs. 

Now, let Zf h represent the set of partitions of the flow s 
over h in its f-th network coding path. Then, J2keic h \ses k 
and J2 z t=z f - h are equivalent, due to the one-to-one mapping 
between the z-th partition and fc-the network code over h. Us- 
age of ^2 zeZ f- h mst ead of EfceK^lseSfc implies the following 
changes; a h = py , H h = H h , and m h = m h . Then, 
the problem reduces to 

f=lh£Af z^zl H 

s.t. Pf" = 1 > Vse5,/ = 1,...,F S (10) 

The objective function in Eq. ( fTOb can be expressed 
as E/=i T, zeZ f T,heAf.* QhH s h ' z /3 s f > z (m^)* where A f < z 
which is the subset of contains the hyperarcs over which 
the z-th partition of the /-th network coding path of flow 
s is transmitted. The two objective functions are equivalent, 
because the indicator functions (H^ k ) are zero for h $ A^' z . 
Finally, the traffic splitting problem for s 6 S,f = l,...,F s 
is expressed as 

zez s s \heAf-* / 

s.t. 0/* = 1 ' Vse5,/ = 1,...,F S (11) 

z&zi 

Similar to what we have done to solve Eq. ©, we use the 
proximal method l22l to solve this problem. 



D. Simulation Results 

In this section, we evaluate the throughput of TCP over 
NCAQM compared to TCP over the following baseline 
schemes: no network coding (noNC), which uses FIFO without 
network coding; BFLY |6), which utilizes knowledge of the 
local topologies by exchanging periodic messages that in- 
cludes neighbors of nodes and source route information in the 
packet headers to exploit butterfly structures in wireless mesh 
networks. Similarly to COPE, BFLY stores native packets in 
a FIFO and decides which packets to code together at each 
transmission opportunity. We used the GloMoSim simulator 
ll23l to implement the modules for two-hop network coding 
over wireless mesh networks (BFLY) as well as for our 
proposed scheme (NCAQM). 

We simulate the butterfly topology shown in Fig. |8]in which 
two unicast flows Si,Ri and 52, i?2 meet at intermediate node 
I\. In this topology, nodes are placed over 300m x 300m in 
butterfly like structure and a single channel is used for both 
uplink and downlink transmissions. We consider the same 
MAC update and wireless channel model as in Section [VT] 
We consider FTP/TCP traffic over the wireless network. TCP 
flows, between the pairs of nodes described above, start at 
random times within the first 5sec and live until the end of 
the simulation. 

Fig. [9ja) presents the average transport-level throughput 
vs. buffer size. Similarly to the simulation results in Sec- 
tion |VI| TCP+NC AQM improves throughput much more than 
TCP+BFLY. Specifically, when buffer size is 10 packets, 
the improvement of TCP+BFLY over TCP+noNC is 13%, 
the improvement of TCP+NCAQM over TCP+noNC is 30%, 
while the optimum improvement is 50%. When buffer size 
increases, we see that TCP+NCAQM approaches and exceeds 
the optimum; e.g., the improvement of TCP+NCAQM is 65% 
when buffer size is 30 packets, while it is 45% for TCP+BFLY. 
This shows that the advantages of TCP+NCAQM also apply 
to two-hop network coded wireless mesh networks. 

Fig. [9ja) presents the average transport-level throughput 
vs. channel capacity. We can see that the improvement of 
TCP+NCAQM is larger than TCP+BFLY for all channel 
capacities and it is especially significant for large channel ca- 
pacities, since TCP+NCAQM uses buffer more effectively and 
drops packets so that network coding opportunities increase. 

VIII. Conclusion 

In this paper, we showed how to improve the performance 
of TCP over wireless networks with inter-session network 
coding. The key intuition was to eliminate the rate mismatch 
between flows that are coded together through a synergy of 
rate control and queue management. First, we formulated 
congestion control as a NUM problem and derived a dis- 
tributed solution. Motivated by the structure of the solution, 
we proposed minimal modifications to queue management to 
make it network coding-aware, while TCP and MAC protocols 
remained intact. Simulation results show that the proposed 
NCAQM scheme doubles TCP performance compared to 
baseline schemes and achieves near-optimal performance. We 
plan to make the simulator modules publicly available to 
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Fig. 9. Average throughput (averaged in Imin simulation first, then over 10 seeds) in butterfly topology shown in Fig. [8] (a) Buffer size: packet size is 
500.B, and the channel capacity is 1Mbps. (b) Channel capacity: buffer size is 30 packets, and packet size 500B. 



the research community. We have also extended the NUM 
formulation and solution to multi-hop network coding and we 
have confirmed convergence through numerical calculations. 
The main ideas of this paper can potentially be extended from 
wireless mesh networks to wired networks with constructive 
inter-session network coding. 
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Appendix A: Numerical Results 

In this section, we present numerical results that demon- 
strate the convergence of the solutions of NUM problems for 
one-hop and multi-hop network coding. 

A. One-hop Network Coding 

First, we consider the Alice-and-Bob topology presented 
in Fig. [2ja). We consider two cases for wireless channel 
capacities: (i) C\ = C% = 1 units/transmissiorlj, and (ii) 
C\ = 1, C2 = 4. For the first case, the convergence of rates 
x\, X2, and x\ + X2 is presented in Fig.flOTa). One can see that 
the total rate x\ + x^ converges to 0.66 which is the optimal 
achievable rate when network coding is used for this scenario. 
Note that total achieved throughput is 0.50 for this scenario 
when network coding is not used. For the second case, it is 
seen in seen in Fig. [TTT a) that the total throughput approaches 
to the optimal achievable rate of 0.88 when network coding is 
used. Note that the total achievable throughput is 0.80 when 
network coding is not used. We also present the convergence of 

5 We omit the units in the rest of the paper for brevity. 
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Fig. 10. Convergence results for the Alice-and-Bob topology presented in Fig. (2{a). The total achieved rate approaches the optimum throughput 0.66. The 
optimum throughput is 0.50 when there is no network coding. Ci = C2 = 1. 
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Fig. 11. Convergence results for the Alice-and-Bob topology presented in Fig. (2{a). The total achieved rate approaches the optimum throughput 0.88. The 
optimum throughput is 0.80 when there is no network coding. C± = 1, C2 = 4. 
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Fig. 12. Convergence results for the X topology presented in Fig. \T\ The total achieved rate approaches to the optimum throughput 0.66. The optimum 
throughput is 0.50 when there is no network coding. C\ = C2 = C3 = C4 = 1. 



Lagrange multipliers; q Aul , q A% ,i, qi,A 2 , ?i,Ai> and ?j,{Ai,a 2 } 
for both cases in Fig. [Bi b) and Fig. [TTT b), respectively. 

Second, we consider the X topology presented in Fig. [TJ 
We consider two cases for wireless channel capacities: (i) 
d = C 2 = C 3 = d = 1, and (ii) d = d = 1, 
d = C3 = 4. In both cases the total rate x\ + X2 approaches 
to the optimum achievable rates; 0.66 and 1.3 as seen in 
Fig- Q~2 a ) an d Fig- Eta). We also show results for the 
convergence of the Lagrange multipliers for both cases in 
Fig- H2b) and Fig. [Bib). 



B. Multi-Hop Network Coding 

We consider the butterfly topology presented in Fig. [8] We 
consider two scenarios for the wireless channel capacities; (i) 
Ci = C* 2 = C 3 = Ci = C 5 = 1 and (ii) d = C 2 = 
C4 = C5 = 4, C3 = 1. The total rate approaches the optimal 
achievable rate in both scenarios: 0.5 for the first case as 
shown in Fig. fBl a). and 1.14 for the second case as shown 
in Fig. [Bl a). In both scenarios, we show the convergence of 
the Lagrange multipliers, Fig. [Bi b) and Fig. [Bi b). 
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Fig. 13. Convergence results for the X topology presented in Fig.[T] The total achieved rate approaches the optimum throughput 1.3. The optimum throughput 
is 0.80 when there is no network coding. C\ = C4 = 1, C2 = C3 = 4. 
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Fig. 14. Convergence results for the butterfly topology presented in Fig. [8] The total achieved rate approaches the optimum throughput 0.50. The optimum 
throughput is 0.33 when there is no network coding. C\ = C2 = C3 = C4 = C5 = 1. 
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Fig. 15. Convergence results for the butterfly topology presented in Fig. [8] The total achieved rate approaches the optimum throughput 1.14. The optimum 
throughput is 0.66 when there is no network coding. G\ = Ci = C4, = C5 = 4, C3 = 1. 



